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Abstract 
This memo updates RFCs 4252 and 4253 to define new public key 
algorithms for use of RSA keys with SHA-256 and SHA-512 for server 
and client authentication in SSH connections. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8332. 
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Overview and Rationale 


Secure Shell (SSH) is a common protocol for secure communication on 
the Internet. In [RFC4253], SSH originally defined the public key 
algorithms "ssh-rsa" for server and client authentication using RSA 
with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1. These 
algorithms are now considered deficient. For US government use, NIST 
has disallowed 1024-bit RSA and DSA, and use of SHA-1 for signing 
[NIST.800-131A]. 


This memo updates RFCs 4252 and 4253 to define new public key 
algorithms allowing for interoperable use of existing and new RSA 
keys with SHA-256 and SHA-512. 


1. Requirements Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


.2. Wire Encoding Terminology 
The wire encoding types in this document -- "boolean", "byte", 
"string", "mpint" -- have meanings as described in [RFC4251]. 


Public Key Format vs. Public Key Algorithm 


In [RFC4252], the concept "public key algorithm" is used to establish 
a relationship between one algorithm name, and: 


A. procedures used to generate and validate a private/public 
keypair; 

B. a format used to encode a public key; and 

C. procedures used to calculate, encode, and verify a signature. 


This document uses the term "public key format" to identify only A 
and B in isolation. The term "public key algorithm" continues to 
identify all three aspects -- A, B, and C. 
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3. New RSA Public Key Algorithms 


This memo adopts the style and conventions of [RFC4253] in specifying 
how use of a public key algorithm is indicated in SSH. 


The following new public key algorithms are defined: 


rsa-sha2-256 RECOMMENDED sign Raw RSA key 
rsa-sha2-512 OPTIONAL sign Raw RSA key 


These algorithms are suitable for use both in the SSH transport layer 
[RFC4253] for server authentication and in the authentication layer 
[RFC4252] for client authentication. 


Since RSA keys are not dependent on the choice of hash function, the 
new public key algorithms reuse the "ssh-rsa" public key format as 
defined in [RFC4253]: 


string "ssh-rsa" 
mpint e 
mpint n 


All aspects of the "ssh-rsa" format are kept, including the encoded 
string "ssh-rsa". This allows existing RSA keys to be used with the 
new public key algorithms, without requiring re-encoding or affecting 
already trusted key fingerprints. 


Signing and verifying using these algorithms is performed according 
to the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as 
hash. 


For the algorithm "rsa-sha2-256", the hash used is SHA-256. 
For the algorithm "rsa-sha2-512", the hash used is SHA-512. 


The resulting signature is encoded as follows: 


string "rsa-sha2-256" / “rsa-sha2-512" 
string rsa_signature_blob 


The value for ’rsa_signature_blob’ is encoded as a string that 
contains an octet string S (which is the output of RSASSA-PKCS1-v1_5) 
and that has the same length (in octets) as the RSA modulus. When S 
contains leading zeros, there exist signers that will send a shorter 
encoding of S that omits them. A verifier MAY accept shorter 
encodings of S with one or more leading zeros omitted. 


Bider Standards Track [Page 4] 


RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018 


3.1. Use for Server Authentication 


To express support and preference for one or both of these algorithms 
for server authentication, the SSH client or server includes one or 
both algorithm names, "rsa-sha2-256" and/or "rsa-sha2-512", in the 
name-list field "server_host_key_algorithms" in the SSH _MSG_KEXINIT 
packet [RFC4253]. If one of the two host key algorithms is 
negotiated, the server sends an "ssh-rsa" public key as part of the 
negotiated key exchange method (e.g., in SSH_MSG_KEXDH_REPLY) and 
encodes a signature with the appropriate signature algorithm name -- 
either "rsa-sha2-256" or "rsa-sha2-512". 


3.2. Use for Client Authentication 


To use this algorithm for client authentication, the SSH client sends 
an SSH_MSG_USERAUTH_REQUEST message [RFC4252] encoding the 
"publickey" method and encoding the string field "public key 
algorithm name" with the value "rsa-sha2-256" or "rsa-sha2-512". The 
"public key blob" field encodes the RSA public key using the 
"ssh-rsa" public key format. 


For example, as defined in [RFC4252] and [RFC4253], an SSH 
"publickey" authentication request using an "rsa-sha2-512" signature 
would be properly encoded as follows: 


byte SSH_MSG_USERAUTH_REQUEST 
string user name 
string service name 
string "publickey" 
boolean TRUE 
string "rsa-sha2-512" 
string public key blob: 
string "ssh-rsa" 
mpint e 
mpint n 
string signature: 
string "rsa-sha2-512" 
string rsa_signature_blob 


If the client includes the signature field, the client MUST encode 
the same algorithm name in the signature as in 
SSH_MSG_USERAUTH_REQUEST -- either "rsa-sha2-256" or "rsa-sha2-512". 
If a server receives a mismatching request, it MAY apply arbitrary 
authentication penalties, including but not limited to authentication 
failure or disconnect. 
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OpenSSH 7.2 (but not 7.2p2) incorrectly encodes the algorithm in the 
signature as "ssh-rsa" when the algorithm in SSH_MSG_USERAUTH_ REQUEST 
is "rsa-sha2-256" or "rsa-sha2-512". In this case, the signature 
does actually use either SHA-256 or SHA-512. A server MAY, but is 
not required to, accept this variant or another variant that 
corresponds to a good-faith implementation and is considered safe to 
accept. 


3.3. Discovery of Public Key Algorithms Supported by Servers 


Implementation experience has shown that there are servers that apply 
authentication penalties to clients attempting public key algorithms 
that the SSH server does not support. 


Servers that accept rsa-sha2-* signatures for client authentication 
SHOULD implement the extension negotiation mechanism defined in 
[RFC8308], including especially the "server-sig-algs" extension. 


When authenticating with an RSA key against a server that does not 
implement the "server-sig-algs" extension, clients MAY default to an 
"ssh-rsa" signature to avoid authentication penalties. When the new 
rsa-sha2-* algorithms have been sufficiently widely adopted to 
warrant disabling "ssh-rsa", clients MAY default to one of the new 
algorithms. 


4. IANA Considerations 


IANA has updated the "Secure Shell (SSH) Protocol Parameters" 
registry, established with [RFC4250], to extend the table "Public Key 
Algorithm Names" [IANA-PKA] as follows. 


- To the immediate right of the column "Public Key Algorithm Name", 
a new column has been added, titled "Public Key Format". For 
existing entries, the column "Public Key Format" has been assigned 
the same value as under "Public Key Algorithm Name". 


- Immediately following the existing entry for "ssh-rsa", two 
sibling entries have been added: 


P. K. Alg. Name P. K. Format Reference Note 
rsa-sha2-256 ssh-rsa RFC 8332 Section 3 
rsa-sha2-512 ssh-rsa RFC 8332 Section 3 


Bider Standards Track [Page 6] 


RFC 8332 Use of RSA Keys with SHA-256 and SHA-512 March 2018 


5. Security Considerations 
The security considerations of [RFC4251] apply to this document. 
5.1. Key Size and Signature Hash 


The National Institute of Standards and Technology (NIST) Special 
Publication 800-131A, Revision 1 [NIST.800-131A] disallows RSA and 
DSA keys shorter than 2048 bits for US government use. The same 
document disallows the SHA-1 hash function for digital signature 
generation, except under NIST’s protocol-specific guidance. 


It is prudent to follow this advice also outside of US government 
use. 


5.2. Transition 


This document is based on the premise that RSA is used in 
environments where a gradual, compatible transition to improved 
algorithms will be better received than one that is abrupt and 
incompatible. It advises that SSH implementations add support for 
new RSA public key algorithms along with SSH_MSG_EXT_INFO and the 
"server-sig-algs" extension to allow coexistence of new deployments 
with older versions that support only "ssh-rsa". Nevertheless, 
implementations SHOULD start to disable "ssh-rsa" in their default 
configurations as soon as the implementers believe that new RSA 
signature algorithms have been widely adopted. 


5.3. PKCS #1 v1.5 Padding and Signature Verification 
This document prescribes RSASSA-PKCS1-v1_5 signature padding because: 


(1) RSASSA-PSS is not universally available to all implementations; 
(2) PKCS #1 v1.5 is widely supported in existing SSH 


implementations; 
(3) PKCS #1 v1.5 is not known to be insecure for use in this scheme. 


Implementers are advised that a signature with RSASSA-PKCS1-v1_5 
padding MUST NOT be verified by applying the RSA key to the 
signature, and then parsing the output to extract the hash. This may 
give an attacker opportunities to exploit flaws in the parsing and 
vary the encoding. Verifiers MUST instead apply RSASSA-PKCS1-v1_5 
padding to the expected hash, then compare the encoded bytes with the 
output of the RSA operation. 
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